Clean Agile
https://scrapbox.io/files/5fadd7fb37faf8002352cf44.png
基本情報
書籍名: Clean Agile 基本に立ち戻れ
ページ数: 192
金額: 2400円+税（紙）
ステータス
本の概要
アジャイルとは何なのか
アジャイルを立ち上げたメンバーの1人が、最新の状況に合わせて、アジャイルを解説する
本の感想
お勧めの読者
アジャイルのことを知らない人
色々な情報を読んでもアジャイルがよく分からない人
扱っている分野
動機、価格
入手日: 2020/10/16
入手金額: 2462円（税込み）
入手フォーマット: Kindle
入手動機: 今ちょうどアジャイル（スクラム）で開発しているため。また2003年頃に学んだアジャイルから先、最新情報を学んでいなかったため知識のアップデートのため。 動機は満たされたか: とても！
関連リンク
引用
これにてアジャイルの概要は終わり - 位置No. 720
アジャイルとは、プロジェクトをイテレーションに分割するプロセスだ。各イテレーションのアウトプットを計測して、スケジュールを継続的に評価する。最も価値のあるものが最初に実装されるように、ビジネス価値の順番で機能を実装していく。クオリティは可能な限り高める。スケジュールはスコープの調整によって管理する。これがアジャイルだ。
プロフェッショナリズム - 位置No. 856
我々の業界では、プロフェッショナリズムが切実に求められている。我々はとにかくよく失敗する。ひどい製品を出荷しすぎている。容認している欠陥が多すぎる。トレードオフが下手すぎる。目に余る振る舞いの多さは、まるでクレジットカードを持ち始めたティーンエイジャーのようだ。物
安定した生産性 - 位置No. 1002
時が経つにつれ、残念なことに、コードベースは雑然としていく。
コードベースが雑然としていけばいくほど、その圧力は高まり、チームの進捗は遅くなる。チームの進捗が遅くなると、スケジュール圧力が高まる。スケジュール圧力が高まると、コードがどんどん雑然としていく。
マネージャーがチームの速度低下に困惑すると、生産性を向上させるために人員の追加投入を決断するかもしれない。
新メンバーはすでに確立されているチームでの振る舞いに従う]ことになる。さらにまずいのが、既存コードが強力な手本になることだ。新メンバーは現状のコードを見て、チームの仕事を推測する。そして、雑然とさせることに加担し、それを続けていくことになる。結果、メンバーは増えたにもかかわらず、生産性は下がり続ける。
マネージャーは再設計に同意する。これに開発者は大喜びする。「ハレルヤ！これで暮らしがまともで、コードがクリーンだった頃に戻れるぞ！」もちろん、そんなことにはならない。
大がかりな再設計は恐ろしいほど高くつくし、それがデプロイまでこぎつけられることはめったにない。
計画ゲームはこのスパイラルを駆動するスケジュール圧力への対抗策となる。
安価に変更できる - 位置No. 1067
「要件変更」は我々のゲームの名前なのだ。
継続的な改善 - 位置No. 1080
これはソフトウェア業界に対する唯一最大の非難である。我々がプロフェッショナルとして失敗していることを示す最も明確な証拠だ。我々は時の経過とともにシステムを悪化させている。我々開発者は、自分たちの構築したシステムについて、時間が経てばだんだんと乱雑に散らかっていき、脆く壊れやすくなっていくと予期している。非常に無責任な態度ではないだろうか。
大胆不敵に力を発揮する - 位置No. 1096
顧客、ユーザー、マネージャーは、開発者に「大胆不敵に力を発揮する」ことを期待している。間違っていたり、汚くなったりしているところを見つけたら、それらを修正してクリーンにしてくれることを期待している。問題を放置して悪化させていくことは期待していない。開発者がコードを完全に把握して、可能な限りクリーンでクリアな状態に保つことを期待しているのだ。
QAは何も見つけない - 位置No. 1114
QA担当者は自分たちの仕事に疑問を抱くべきだ。なぜシステムが動作することを確認するプロセスの後方に立たされているのかと。
テストの自動化 - 位置No. 1135
わざわざQAを雇うなら、もっとよい仕事をさせるべきだ。人間としての創意工夫と想像力を活用してもらうのだ。詳しくはあとで説明する。
手動テストは、自動テストでは検査できないものや、探索テストのように独創性と専門性が求められる箇所に限定すべきである。
「ノー」と言うべき - 位置No. 1173
自分が雇われている理由は、コードを書く能力よりも「ノー」と言える能力のためだと自覚すべきだ。プログラマーであるあなたにしか、できるかどうかの判断はできないのだ。私はCTOとして、我々が崖っぷちに立たされているなら、あなたにはそれを知らせてくれることを期待する。どれだけ納期のプレッシャーを感じていても、どれだけ多くのマネージャーたちが結果を求めていても、答えが本当に「ノー」であるなら、「ノー」と言うことを期待する。
顧客 - 位置No. 1215
事前に計画を立てることはアジャイル開発ではない、と主張する人が多い。冒頭に掲げられている顧客の権利は、その主張が偽りであることを示している。当然だが、ビジネスには計画が必要だ。そして、計画には納期とコストが含まれる。そうした計画には、実用に足る正確さと精度が必要である。
つまり、動かせない納期までに固定されたスコープを納品することには承諾できないのだ。スコープも納期も調整可能でなければならない。
顧客にはこうした確率ベースの計画を知る権利がある。計画がなければビジネスを成立させられないからだ。
顧客にはスケジュールの順守を要求する権利がないことに注意してほしい。顧客の権利は、スコープの変更によるスケジュールの管理に限定されている。この権利のなかで最も重要なのは、スケジュールに危険が及んでいることを 知る 権利である。
ビジネス側の人たちに、開発者のプロフェッショナルとしての信用や倫理を裏切るようなことを強要する権利はない。
見積りは推測だ。思慮分別のある推測かもしれないが、それでも推測は推測だ。そしてそれは、時間が経つとともによくなる推測でもある。しかし、見積りは決してコミットメントにはならない。
1312
プログラマーとは、タスクをコード行に分割できるスキルを持つ人のことを指す。
大きなタスクに有効な技法として 三点見積り がある。この見積りは、 最良ケース、 最有力ケース、 最悪ケース の3つの数値で構成される。これらの数値は、 信頼性を持つ 見積りだ。 最悪ケース の数値はタスクが95%の信頼性で完了する時間を示している。同様に、 最有力ケース は50%の信頼性、 最良ケース は5%の信頼性を持っている。
1354
「あとで会話をする」という約束を表すものとして、ストーリーを省略形にしているのである。
詳細化を避けるのは 鍛錬 である。これが非常に難しい。チームにいる誰もが、話し合った詳細をすべて書き留めるべきだと思っている。だが、そのような衝動に抵抗するんだ！
ストーリーをマネジメント可能、スケジュール可能、見積り可能にするためには、「 一時的な詳細の欠如」が必要である。ストーリーは安価に始めなければいけない。その多くが変更・分割・統合・破棄されるからだ。ストーリーはプレースホルダーであり、要件ではないことを覚えておこう。
1455
完成したストーリーは合計で10ポイントだった。あと1週間しかない。これから20ポイントできる可能性は低い。したがって、残りのポイントが10になるように、ステークホルダーが計画からストーリーを削除する。
1486
詳細はストーリーではなく、 受け入れテストとして記録する。
ストーリーは、 INVEST という頭字語のガイドラインに従う 1502
リファクタリングはストーリーではない。
アーキテクチャはストーリーではない。
コードのクリーンアップはストーリーではない。
ストーリーには常にビジネス価値が存在しなければいけない。
心配しないでほしい。リファクタリング、アーキテクチャ、クリーンアップについては、 あとで触れる。だが、ストーリーのところではない。
1527
たとえば、「ログイン」の詳細を知る必要はないが、それがテスト可能であることは知る必要がある。「ログイン」は具体的な操作だからだ。一方、「使いやすい」のようなストーリーはテスト可能ではない。また、見積りもできない。このように「見積り可能」と「テスト可能」は非常に近い存在である。
1561
スパイク と呼ばれるのは、システムのすべてのレイヤーを通る、先の尖った細長いものを開発することが多いからだ。 見積りができないストーリーを考えてみよう。ここでは「PDFの印刷」にしよう。どうして見積りができないのだろうか？ PDFライブリを使ったことがなく、その仕組みもわからないからだ。そこで「PDFの印刷のストーリーを見積もる」という新しいストーリーを書いた。これなら見積りができるはずだ。 つまり、PDFライブラリの仕組みを理解するために、何をする必要があるかを把握するということだ。両方のストーリーをデッキに入れておこう。 1,576
マネージャーやリーダーは、ストーリーをプログラマーにアサインしようとするだろう。だが、これは避けるべきだ。プログラマーに自分たちで話し合ってもらうほうがはるかに有益だ。
1,595
受け入れテストの記述はすぐに終わらせよう。イテレーションの中間地点までにはすべてを記述しておきたい。それまでに終わっていなければ、何人かの開発者がストーリーの開発を中断して、受け入れテストを書くべきだ。
1,600
中間地点を過ぎて、すべての受け入れテストができていたら、QAは次のイテレーションのテストに取り掛かろう。まだIPMを実施していないのであくまでも推測になってしまうが、ステークホルダーから選択しそうなストーリーを教えてもらうといいだろう。
1,608
イテレーションの最終日には、どのストーリーを完成させ、どのストーリーを放置するかという、厳しい選択が必要になるだろう。できるだけ多くのストーリーを完成できるように、労力を再配分するためだ。繰り返しになるが、2つのストーリーをそれぞれ半分ずつ完成させてイテレーションを終わるよりも、片方を犠牲にして1つのストーリーをきちんと完成させるべきである。
1,621
イテレーションの最後の作業は、ベロシティとバーンダウンチャートの更新である。受け入れテストをパスしたストーリーのポイントだけをチャートに記録する。
1,630
プレッシャーが高まると、チームは無意識に見積りの値を変えて、速度が上がっているかのように見せるようになる。 これは単なるインフレだ。ストーリーのポイントは通貨のようなものであり、チームは外部からのプレッシャーによって価値を切り下げているのである。
1,640
ベロシティのチャートの傾きが常に負になっている場合は、コードの品質に問題がある可能性が高い。おそらくリファクタリングが十分ではなく、コードの腐敗が進んでいるのだろう。リファクタリングが十分ではない理由は、ユニットテストを書いていないからであり、リファクタリングすると動いていたものが壊れてしまうことを恐れているからだ。こうした変更の恐怖をうまく管理することが、チームマネジメントの主な目的である。
1,739
仕様とは何か？ 仕様とは テストである。
1,778
受け入れテスト のプラクティスはシンプルである。ビジネス側がユーザーストーリーの振る舞いを形式的なテストで記述し、開発者がそれらのテストを自動化するだけだ。
1,785
ビジネスアナリストは、 ハッピーパス（ 正常系）を仕様化する。
QAの役割は、ハッピーではないパスを書くことだ。
1,787
QAの人たちはシステムを破壊する方法を見つける能力を買われて雇われている。深い専門性を持った人たちであり、ユーザーがシステムに対して行うあらゆる奇妙なことを予見できる。プログラマーの心を熟知しており、プログラマーが怠惰なところを徹底的に調査する方法を理解している。
1,791
これまでのQAの役割とは完全に異なる。プロジェクトの後方でテスターとして活動するのではなく、前方で活躍する仕様作成者となるのだ。事後にエラーやミスを報告するのではなく、開発チームがエラーやミスをしないように事前に情報を提供するのである。
1,794
QAには大きな負担となるだろう。イテレーションの最後に整合性を評価するのではなく、イテレーションの最初から品質を作り込み、品質を担保しなければいけない。それでいて、QAの責任が軽減されることはなく、システムがデプロイ可能かどうかも判断する必要が
1,820
QAがイテレーションのストーリーの受け入れテストを書く。 ただし、QAはこれらのテストを実行しない。 テストをパスするかを検証するのはQAの仕事ではない。では、誰の仕事なのか？ 当然、プログラマーの仕事である！ テストを実行するのは、プログラマーの仕事である。自分のコードがすべてのテストをパスすることを確認するのは、プログラマーの仕事である。テストを実行するのは、もちろんプログラマーである。ストーリーが完成したかどうかをプログラマーが判断するには、テストを実行する以外に方法は
1,870
誤解しないでほしい。チームメンバーが家から仕事をすると、非言語的コミュニケーションが大きく損なわれる。偶発的な会話も発生しづらい。電子的に接続されていても、チームは同じスペースにいるわけではない。これは明らかに不利だ。同じスペースにいれば、会話や即席のミーティングなどが常に行われる。家で仕事をしているとそれらが失われる。帯域幅が広くなったことは楽しいかもしれないが、同じ場所で働いている人たちと比べると、のぞき穴からコミュニケーションしているようなものである。 1,932
このメタファーは我々のコミュニケーションには有効だったが、お金を支払ってくれる人たちに対する敬意を欠いていた 1,947
簡単な例として、私が最近書いた「SpaceWar」というビデオゲームを取り上げよう。データの要素は「宇宙船」「クリンゴン」「ロミュラン」「命中」「爆破」「基地」「輸送」などだ。私はこれらの概念を注意深くモジュールに切り出した。そして、アプリケーションではこれらの名前のみを使うようにした。こうした名前が私の「ユビキタス言語」である。
1975
持続可能なペース
https://scrapbox.io/files/607e6930c56b0b0023d295d9.png
有能なプログラマーは我々だけではなかった。週に40時間だけ働く人たちがいたのである。我々が「献身的ではない怠惰な人たち」とバカにしていた人たちだ。彼らが黙って手綱を握り、システムをうまく持続させたのである。
2,004
残業したからといって、雇用主に献身的であることを示したことにはならない。
2,020
プログラマーの生活で最も重要なのは十分な睡眠である。
2,022
睡眠が1時間不足すると、昼間の仕事が2時間余計にかかる。2時間不足すると、4時間余計にかかる。3時間不足すると、生産的な仕事はまったくできない。
2,120
納期のプレッシャーから、継続的ビルドを失敗させたままにするチームがある。これは自滅的な行為だ。
2,148
これまでに私がやってよかったと思った変更は、4番目に任意の質問を追加することである。 ●誰に感謝したいか？ これは、あなたを手伝ってくれた人や称賛に値する行動をした人に、手短に感謝を述べるもので
2,179
「TDD」「リファクタリング」「シンプルな設計」そしてもちろん「ペアプログラミング」。これらがなければ、アジャイルは本来意図されたものではない、骨抜きにされた役立たずなものになってしまうだろう。
2,398
設計が複雑になれば、プログラマーにかかる認知的負荷は大きくなる。この認知的負荷が 設計のウェイト だ。設計のウェイトが増えれば、プログラマーがシステムを理解したり操作したりするのに必要な時間や労力が増える。
2,430
シニアプログラマーは同じシニアプログラマーとペアになるよりも、ジュニアプログラマーとペアになるべきだ。ジュニアプログラマーは同じジュニアプログラマーに相談するよりも、シニアプログラマーに相談する機会を増やすべきだ。専門分野を持つプログラマーは、専門外のプログラマーとペアになるべきだ。知識を集めるのではなく、知識を交換することがゴールである。
2,448
直接的なコストは15%増になる
2,470
何かをする許可を求めてはいけない。あなたは専門家だ。あなたが決めよう。